3.13 support by 15r10nk · Pull Request #80 · alexmojaki/executing

15r10nk · 2024-01-27T17:38:30Z

First of all It was kind of an accident that I pushed directly into your repository, is it OK?

This is the start of the 3.13 support.

fixes #79

The existing tests work, but there are some open issues:

("STORE_FAST_STORE_FAST", "STORE_FAST_LOAD_FAST", "LOAD_FAST_LOAD_FAST") are used to load/store two variables, but they map only to one position of one ast.Name. It is not possible for one bytecode to map to multiple locations. I think there is no other option for us than to accept the fact that we are not able to map this instructions to ast nodes.
I have only checked the existing tests so far and not searched for new samples.

alexmojaki · 2024-01-27T18:29:49Z

First of all It was kind of an accident that I pushed directly into your repository, is it OK?

Yes, using a branch instead of a fork is better.

alexmojaki · 2024-01-27T18:55:30Z

("STORE_FAST_STORE_FAST", "STORE_FAST_LOAD_FAST", "LOAD_FAST_LOAD_FAST") are used to load/store two variables, but they map only to one position of one ast.Name. It is not possible for one bytecode to map to multiple locations. I think there is no other option for us than to accept the fact that we are not able to map this instructions to ast nodes.

This is fine. Like you say, I don't even know what we'd do. But also, identifying ast.Name has barely any value. And I think it should be virtually impossible to actually get hold of a frame paused at that point. I can't see a way for one of those instructions to raise an exception - if they could, what would the Python traceback highlight?

15r10nk · 2024-01-27T19:05:15Z

if they could, what would the Python traceback highlight

probably the first name.
I think I have a backtrace which could trigger something like this.

def a():
    def b():
        nonlocal e

        e += 1

    b()
    e = 5


a()

output (Python 3.13.0a3+):

Traceback (most recent call last):
  File "/home/frank/projects/executing/codi.py", line 11, in <module>
    a()
    ~^^
  File "/home/frank/projects/executing/codi.py", line 7, in a
    b()
    ~^^
  File "/home/frank/projects/executing/codi.py", line 5, in b
    e += 1
    ^
NameError: cannot access free variable 'e' where it is not associated with a value in enclosing scope

it is currently the same variable. so no issue here, but it is a backtrace which refers to an ast.Name.

15r10nk · 2024-01-27T19:07:35Z

I take it back, this is a LOAD_DEREF. The bytecode is only combined for LOAD_FAST.

15r10nk · 2024-01-28T07:55:29Z

found the first cpython 3.13 issue python/cpython#114671

frenzymadness · 2024-06-04T07:45:29Z

What is the status, please? The second beta of 3.13 should be out today.

15r10nk · 2024-06-04T16:49:28Z

I fixed some tests for 3.13.0b1 and it is working for 3.13 now, but the ci is failing for 3.5.

@alexmojaki should we start to deprecate some python versions?

alexmojaki · 2024-06-04T17:15:51Z

Yes, we can drop <3.8

frenzymadness · 2024-06-05T11:44:24Z

Thank you! With the patch from this PR, I can confirm that the RPM package in Fedora Linux with Python 3.13 builds fine.

15r10nk · 2024-06-05T12:52:26Z

I have still some problem with the tests (like python/cpython#120108) but I think that we are on a good way.

frenzymadness · 2024-07-17T10:14:38Z

Python 3.13 beta 3 is out and beta 4 will be released soon.

executing/_position_node_finder.py

alexmojaki · 2024-08-10T14:37:17Z

executing/_position_node_finder.py

+                )
+            ):
+                # closures
+                # TODO: better check that this is actualy a closure for a scope of a type variable


Can this TODO be resolved? This condition looks very lenient

The following code shows an example:

The code is not only generated for type variables (I fixed the comment).

Checking the variable name could be expensive to compute, because we would have to check large ast trees for variable names.

We could check for the LOAD_FAST,BUILD_TUPLE,LOAD_CONST,MAKE_FUNCTION,SET_FUNCTION_ATTRIBUTE pattern and allow the LOAD_FAST in these cases.

Please just leave a more detailed comment, maybe a link to this discussion.

tests/test_main.py

…nown issues

…class

… the end position

…cursion limit has no effect

alexmojaki · 2024-08-25T08:46:01Z

Is this ready for review again?

15r10nk · 2024-08-25T16:25:24Z

yes, you can review it.

alexmojaki · 2024-08-25T16:57:35Z

executing/_position_node_finder.py

+
+            if instruction.opname == "LOAD_FAST" and instruction.argval == "__class__":
+                raise KnownIssue(
+                    f"loading of __class__ is accociated with a random node at the end of a class"


Seems like this could also arise normally - what about checking if the node is a Name(id='__class__')?

The check would not work.

class T: def a(): super() some_node

The node in this case is Name(id='some_node')

is it a random node, or is it always class_node.body[-1]?

It is not "random", but the last node cpython has worked on(this is my current assumption).

It is the assigned name in this case:

class T: def a(): super() some_node=not_the_node()

I don't think that we can build any solid rule for these cases.

alexmojaki · 2024-08-25T17:06:36Z

executing/_position_node_finder.py

+                )
+            ):
+                # closures
+                # TODO: better check that this is actualy a closure for a scope of a type variable


Please just leave a more detailed comment, maybe a link to this discussion.

alexmojaki

Thank you!

15r10nk · 2024-08-26T10:46:55Z

@alexmojaki, would prefer a normal merge-commit for this review.
The reason is that the different commits are useful to connect the small_samples with the code changes.

I would merge it if it is ok for you.

alexmojaki · 2024-08-26T10:48:05Z

OK, if you prefer that

15r10nk force-pushed the 3.13 branch from c0e66d6 to b2fb635 Compare June 26, 2024 07:23

15r10nk marked this pull request as ready for review July 24, 2024 08:59

alexmojaki requested changes Aug 10, 2024

View reviewed changes

15r10nk added 16 commits August 25, 2024 06:55

fix(3.13): show_caches is deprecated

629d978

fix(3.13): added new rules to the verification

d2e50a1

build(3.13): added 3.13 to ci workflow

a855297

fix(3.13): fixed typing errors

7d6a107

fix(3.13): handle STORE_FAST_STORE_FAST and similar instructions as k…

6bca899

…nown issues

fix(3.13): loading of __class__ is mapped to the last element of the …

6fb0fac

…class

fix(3.13): handle CALL_KW like method calls which are only located by…

8c2d3a3

… the end position

fix(3.13): a lambda can also have nonlocal variables

58f7489

fix(3.13): a async function can also have nonlocal variables

b9a2921

fix(3.13): COMPARE_OP maps always to ast.Compare

edad4a3

fix(3.13): a type variable can also have nonlocal variables

0490384

test(3.13): handle optimization of not not x

14f94d7

test: fixed tests for 3.13.0b1

27b446f

fix: allow to LOAD_FAST variables for TypeVars

e1e4ac8

fix: skip files with raise an recursion error in 3.13, because the re…

315d1df

…cursion limit has no effect

test(3.13): added sample_results

6425ffb

15r10nk added 4 commits August 25, 2024 07:39

test: skip module tests for now

d55eb52

refactor: review changes

dc03e8c

fix: handle __firstlineno__

c4f1862

fix: removed unused verification

960dee1

15r10nk force-pushed the 3.13 branch from 945bf2a to 960dee1 Compare August 25, 2024 06:00

alexmojaki reviewed Aug 25, 2024

View reviewed changes

doc: review changes

de6b2fa

alexmojaki approved these changes Aug 26, 2024

View reviewed changes

15r10nk merged commit ea6a695 into master Aug 26, 2024

15r10nk deleted the 3.13 branch August 31, 2024 06:21

Conversation

15r10nk commented Jan 27, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexmojaki commented Jan 27, 2024

Uh oh!

alexmojaki commented Jan 27, 2024

Uh oh!

15r10nk commented Jan 27, 2024

Uh oh!

15r10nk commented Jan 27, 2024

Uh oh!

15r10nk commented Jan 28, 2024

Uh oh!

frenzymadness commented Jun 4, 2024

Uh oh!

15r10nk commented Jun 4, 2024

Uh oh!

alexmojaki commented Jun 4, 2024

Uh oh!

frenzymadness commented Jun 5, 2024

Uh oh!

15r10nk commented Jun 5, 2024

Uh oh!

frenzymadness commented Jul 17, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alexmojaki commented Aug 25, 2024

Uh oh!

15r10nk commented Aug 25, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexmojaki left a comment

Choose a reason for hiding this comment

Uh oh!

15r10nk commented Aug 26, 2024

Uh oh!

alexmojaki commented Aug 26, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

15r10nk commented Jan 27, 2024 •

edited

Loading